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1.  INTRODUCTION 


1.1  PURPOSE 

This  document  is  the  Final  Technical  Report  delivered  under  the  CATSS  Data  Base 
Development  contract.  The  project  scope  included  a  broad  survey  and  assessment  of  USAF  digital 
cartographic  data  requirements  and  development  of  a  laboratory  data  base  system  for  ingesting, 
structuring,  and  analyzing  spatial  cartographic  data.  This  report  summarizes  the  project  objectives, 
deliverables,  and  technical  accomplishments  pertaining  to:  the  requirements  survey  and  data 
analysis,  and  development  of  the  laboratory  data  base  system.  The  Final  Technical  Report 
represents  an  overview  of  the  project  although  the  reader  is  advised  to  consult  other  project 
documentation  (see  Section  2.2)  regarding  specific  results  of  the  requirements  analysis  or 
description  of  the  developed  laboratory  system. 


1.2  CONTENTS 


The  organization  of  the  Technical  Report  is  as  follows: 

•  Section  2  presents  the  project  purpose  and  summarizes  the  effort’s  key  accomplish¬ 
ments.  Also,  all  deliverable  documents  are  identified. 

•  Section  3  provides  a  description  of  the  digital  cartographic  data  requirements  analysis 
and  associated  data  base  of  requirements  information,  and  describes  the  characteristics 
of  the  resultant  DCD  product  specification. 

•  Section  4  presents  an  overview  of  the  laboratory  data  base  system,  including  the  system 
design,  data  base  structure,  system  configuration,  and  user  functionality. 

1.3  ACRONYMS 


The  acronyms  used  in  this  report  are  identified  below. 


AFSC 
AOI 
AS  I 
C3 

CATSS 

CCT 

CONUS 

COTS 


-  Air  Force  Systems  Command 

-  Area  of  Interest 

-  Applications  Software  Interface 

-  Command,  Control,  and  Communications 

-  Cartographic  Applications  for  Tactical  and  Strategic  Systems 

-  Computer  Compatible  Tape 

-  Continental  United  States 

-  Commercial  Off-the-Shelf 
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CTAF 

- 

Cartographic  Traceability  and  Analysis  Function 

DBA 

- 

Data  Base  Administrator 

DCA 

- 

Digital  Cartographic  Applications 

DCD 

- 

Digital  Cartographic  Data 

DCE 

- 

Data  Capture  and  Edit 

DCL 

- 

Digital  Command  Language 

DFAD 

- 

Digital  Feature  Analysis  Data 

DLMS 

- 

Digital  Land  Mass  System  (comprised  of  DFAD  and  DTED  Products) 

DMA 

- 

Defense  Mapping  Agency 

DMASC 

- 

DMA  Systems  Center 

DPS 

- 

Digital  Production  System 

DTED 

- 

Digital  Terrain  Elevation  Data 

FACS 

- 

Feature  Attribute  Coding  Standard 

GFE 

- 

Government  Furnished  Equipment 

GIS 

- 

Geographic  Information  Systems 

IFF 

— 

Interim  File  Format 

IRRP 

- 

Image  Systems  Division,  Products  Branch 

MMI 

- 

Man-machine  Interface 

NFF 

- 

Neutral  File  Format 

NRT 

- 

Near-Real  Time 

RDBMS 

- 

Relational  Data  Base  Management  System 

RL 

- 

Rome  Laboratory 

RTNEPH 

- 

Real  Time  Nepthanalysis 

SLF 

- 

Standard  Linear  Format 

SOF  ATS 

- 

Special  Operations  Forces  Aircrew  Training  System 

TM 

- 

Thematic  Mapper 

TTD 

- 

Tactical  Terrain  Data 

USGS 

- 

U.S.  Geological  Survey 

VOD 

- 

Vertical  Obstruction  Data 

WDB  n 

— 

World  Data  Bank  II 
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2.  PROJECT  PURPOSE  AND  ACCOMPLISHMENTS 


2.1  OVERVIEW  OF  PROJECT  OBJECTIVES 

The  CATSS  Program  is  a  major  initiative  by  RL  and  the  USAF  with  the  goal  to  achieve 
overall  effectiveness  in  applying  digital  cartographic  data  to  a  wide  and  growing  spectrum  of 
USAF  systems.  The  purpose  of  this  phase  of  the  CATSS  Program  was  to  establish  a  laboratory 
system  that  would  provide  the  technical  base  to  define  and  validate  data  requirements,  establish 
standards  for  data  content/structures,  and  develop  algorithms  and  applications  software  for  func¬ 
tional  prototyping  and  demonstrations.  This  laboratory  capability  will  allow  future  system 
developers  to  capitalize  on  previous  accomplishments  and  consequently  minimize  technical  risk  and 
cost  during  system  specification  and  development 

The  Data  Base  System  (DBS)  is  a  key  component  of  the  CATSS  Program  and  supports  the 
evaluation  and  technical  definition  of  USAF  requirements  for  digital  cartographic  data  content  and 
structure(s).  RL’s  intent  is  to  establish  a  laboratory  capability  to  ingest  and  integrate  data 
structures/formats  required  for  representative  system  functions  and  applications.  This  laboratory 
capability  will  entail  the  creation  of  data  structures  that  will  support  weapon  system  functions  and 
algorithms.  The  accomplishment  of  these  activities  will  provide  the  proof  of  concepts  regarding 
data  content/structures,  algorithms,  and  functional  software.  Specific  challenges  of  the  DBS 
design  and  development  included  techniques  and  methods  to  deal  with:  the  various  digital  source 
data  bases,  which  are  disparate  in  terms  of  data  coding,  format,  and  spatial  structure. 

2.2  PROJECT  DELIVERABLES 

The  following  documents  comprise  the  complete  list  of  project  deliverables,  including  this 
Final  Technical  Report  (FTR): 

Item  Name 

A001  Monthly  Status  Repons,  November  1987  through  January  1991. 

A002  Software  Requirements  Specification  for  the  CATSS  Laboratory  Data  Base 
Development  System,  25  July  1988. 

A 003  Software  Top  Level  Design  Document  for  the  CATSS  Laboratory  Data  Base 

Development  System,  30  December  1988. 

A004  Interface  Requirements  Specification  for  the  CATSS  Laboratory  Data  Base 
Development  System,  14  September  1989. 
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A005 


Interface  Design  Document  for  the  CATS S  Laboratory  Data  Base  Development 
System,  20  January  1989. 

A006  Data  Base  Design  Document  for  the  CATSS  Laboratory  Data  Base  Development 
System,  May  1989. 

A007R  Software  Product  Specification  for  the  Cartographic  Applications  for  Tactical  and 
Strategic  Systems  (CATSS)  Laboratory  Data  Base  System,  26  September  1990. 

A008R  Software  Programmer’s  Manual  for  the  Cartographic  Applications  for  Tactical 

and  Strategic  Systems  (CATSS)  Laboratory  Data  Base  System,  15  August  1990. 

A009R  Software  User’s  Manual  for  the  CATSS  Laboratory  Data  Base  System, 

13  August  1990. 

A010R  Software  Test  Plan  for  the  CATSS  Data  Base  Development  System,  6  February 
1990. 

A011  Technical  Report  (Final),  22  March  1991. 

A0 12+  United  States  Air  Force  Digital  Cartographic  Data  Product  Specification,  Volumes 
I,  II,  and  III,  January  1989. 

2.3  PROJECT  ACCOMPLISHMENTS 

The  following  discussion  provides  highlights  of  key  project  accomplishments  and  system 
development  strategies. 

USAF  Cartographic  Data  Requirements  Analysis:  The  USAF  requirements 
information  was  substantially  outdated  at  the  rime  of  project  initiation  and  was  in  need  of  a  major 
update.  PGSC  and  RL  jointly  developed  a  comprehensive  plan  for  surveying  of  DCD 
requirements  which  PGSC,  RL,  and  Defense  Mapping  Agency  (DMA)  personnel  conducted 
during  the  1988  time  frame.  Over  100  system  environments  were  identified  with  current  or 
projected  data  requirements.  Automated  tools  were  developed,  including  relational  data  base  and 
query/  report  software,  to  organize,  query,  and  summarize  the  information  collected.  The  original 
data  base  still  exists  under  a  VAX  Ultrix  environment  using  the  Informix  relational  data  base 
management  system  (RDBMS).  Portions  of  the  requirements  data  were  also  loaded  into  the  RL 
CTAF  data  base  under  a  separate  activity. 

Incorporation  of  Evolving  Data  Standards:  Early  in  the  project  the  decision  was 
made  to  standardize  data  formats  and  coding  schemes  where  appropriate.  The  DMA  Feature 
Attribute  Coding  System  (FACS),  being  developed  under  the  Digital  Production  System  (DPS) 
Mark  90  (Section  100  Glossary  of  Features  and  Attributes),  was  adopted  as  the  basis  for  both  the 
requirements  survey  and  the  Data  Base  System  development.  Thus,  the  methodology  for  defining/ 
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recording  feature  and  attribute  requirements  and  laboratory  data  base  research  under  the  DBS  are 
consistent  with  the  DMA  coding  standards.  No  single  DoD  or  DMA  standard  exists  for  spatial  data 
representation.  The  past  standards,  including  SLF  and  DLMS,  as  well  as  the  evolving  prototype 
Mini-topo  data  format  and  topology  conventions,  were  considered  in  the  design.  Given  the 
requirement  to  integrate  data  derived  from  the  DMA  standard  products,  a  Mini-topo  ‘like’  structure 
was  selected  because  it  represented  the  most  complex  data  structure  (i.e.,  three-dimensional  and 
fully  integrated  topology)  to  be  processed  in  the  laboratory. 

System  Configuration  Strategy:  Development  of  the  CATSS  DBS  —  co-located  on 
the  CATSS  VAX  (VMS)  and  a  Sun  3/60  Workstation  —  was  completed  and  is  operational.  Soft¬ 
ware  on  the  CATSS  VAX  includes  primarily  FORTRAN  code,  several  C  programs,  and  DCL 
command  files  (including  Remote  Copy  functions)  to  provide  user  interface  with  programs  located 
on  the  CATSS  VAX  or  on  the  Sun  Workstation.  Software  on  the  Sun  includes  C  programs, 
shellscripts,  menus,  and  the  System  9  GIS  COTS  package  which  support  data  input/output  and 
data  base  graphic  display,  editing,  and  analysis. 

Digital  Product  Data  Import  and  Export:  The  CATSS  DBS  supports  loading  into 
the  on-line  data  base  and  subsequent  manipulation/output  of  the  formats  noted  below.  As  shown 
in  Figure  2-1,  the  data  formats  are  converted  from  their  native  product  formats  to  a  common 
Interim  File  Format  (IFF)  for  import/export  to/from  the  GIS  package.  The  IFF  is  generated  by  the 
various  ‘prep’  routines  as  input  to  the  dbs_dim  (data  input  module)  and  generated  by  the  dbs_dom 
(data  output  module)  for  input  to  the  various  ‘deprep’  routines.  This  implementation  approach 
allows  for  the  future  addition  of  other  prep/deprcp  routines  to  input/output  additional  product  types 
(e.g..  Digital  Chan  of  the  World,  etc.).  It  also  isolates  the  entire  suite  of  prep/deprep  conversion 
software  residing  on  the  CATSS  VAX  and  on  the  Sun  so  that  version  upgrades  to  the  DBS  —  or 
even  interface  to  another  GIS  —  will  have  minimal  impact. 

Inmfpnnats; 

•  Digital  Feature  Analysis  Data  (DFAD)  in  DLMS  format,  including  Edition  1  (without 
Data  Set  Identifier  (DSI)  and  Accuracy  (ACC)  records)  and  Edition  2  (with  DSI  and 
ACC  records) 

•  Digital  Terrain  Elevation  Data  (DTED)  in  DLMS  format,  including  Edition  1  (without 
Data  Set  Identifier  (DSI)  and  Accuracy  (ACC)  records)  and  Edition  2  (with  DSI  and 
ACC  records) 

•  Interim  Terrain  Data  in  Standard  Linear  Format  (SLF) 
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•  Tactical  Terrain  Data  (TTD)  in  Mini-topo  (vertically  and  horizontally  integrated)  format 

•  Vertical  Obstruction  Data  (VOD) 

•  Real  Time  Nepthanalysis  (RTNEPH)  weather  data 

•  Landsat  Thematic  Mapper  (TM)  Computer  Compatible  Tape  (CCT)  format 

•  World  Data  Bank  II  (WDB  II)  for  user  review  and  locational  reference  at  meta-data 
level 

Output  Formats; 

•  HD  in  SLF  format,  including  the  capability  to  generate  text  (i.e.,  TXT  block  defined  by 
the  SLF  specification) 

•  DFAD  in  the  DLMS  format 

•  Digital  Cartographic  Applications  (DCA)  Neutral  File  Format  (NFF),  which  provides 
data  to  the  CATSS  DCA  functions 


Integrated  Data  Base  Structure:  The  CATSS  DBS  supports  the  concept  of  a  three- 
dimensional,  seamless  data  base  with  the  capability  to  handle  horizontally  and  vertically  topological 
cartographic  data.  The  CATSS  DBS  currently  records  the  spatial  extents  and  meta-data  for  each 
data  set  directly  loaded  into  the  DBS.  A  basic  tiling  scheme  was  implemented  which  subdivides 
the  earth  into  regular  squares  (variable  in  number  although  currently  set  at  eight).  With  this  scheme 
only  meta-data  represents  the  tiled  areas  and  actual  data  is  physically  removed  from  the  ‘active’  data 
base  until  the  user  requests  the  area  of  interest.  A  Global  Project  maintains  meta-data  and  spatially 
indexes  all  DBS  holdings. 
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3.  DIGITAL  CARTOGRAPHIC  REQUIREMENTS  ANALYSIS 


This  section  presents  a  review  of  the  methodology  used  to  determine  and  present  Air  Force 
digital  cartographic  data  (DCD)  requirements.  It  summarizes  the  purpose  and  structure  of  the  DCD 
Requirements  Data  Base.  A  review  of  the  resultant  USAF  DCD  Product  Specification  is  then 
presented. 

3.1  ANALYSIS  METHODOLOGY 

3.1.1  Purpose  and  Scope  of  Requirements  Definition 

CATSS  DCD  requirements  definition  encompasses  Air  Force  system  requirements  for 
navigation;  geopositioning;  weapon  delivery;  display;  intelligence  analysis;  mission  planning; 
command,  control,  and  communications  (C3);  and  avionics  support.  DCD  requirements  for  Air 
Force  training  systems  and  visual  and  sensor  simulators  were  specifically  excluded  because  HQ 
AFSC  has  delegated  these  requirements  to  the  Training  Systems  System  Program  Office, 
ASD/YW,  under  the  tri-Service  sponsored  and  approved  Project  2851. 

The  DCD  specification  developed  under  this  contract  identifies  current  and  evolving  Air 
Force  digital  cartographic  data  requirements  addressed  during  a  HQ  USAF-sponsored  survey  of 
Air  Force  systems  conducted  in  FY88.  The  survey  included  both  operational  systems  and  systems 
or  technologies  under  development  whose  performance  depends  on  or  may  be  improved  through 
the  use  of  digital  cartographic  data. 

The  CATSS  Requirements  Data  Base,  and  the  USAF  DCD  Product  Specification  derived 
from  it,  result  from  an  in-depth  investigation  of  Air  Force-wide  DCD  requirements.  Although  the 
initial  information  cutoff  date  for  this  specification  was  19  August  1988,  more  current  survey 
information  has  been,  and  continues  to  be,  received  by  the  CATSS  Program  Office  at  RL. 
Accordingly,  the  data  base  and  the  resultant  specification  will  require  follow-on  update. 

The  raw  survey  technical  requirements  collected  by  the  CATSS  team  and  reported  in  the 
specification  have  not  been  formally  validated  by  HQ  USAF/INTB.  The  mission  of  the  RL 
CATSS  is  to  systematically  collect  the  requirements  data  and  to  objectively  represent  the  technical 
issues  in  the  specification.  Resolution  of  the  issues  and  validation  of  the  requirements  are  a  joint 
responsibility  of  HQ  USAF/INTB  and  HQ  DMA/PR. 
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3.1.2  Survey  Procedures 


The  joint  RL/PGSC  project  team  determined  that  the  DCD  requirements  should  be 
baselined  and  defined  within  the  context  of  the  Defense  Mapping  Agency’s  evolving  MARK  90 
Feature  Attribute  Coding  Standard  (FACS).  By  doing  so,  modifications  (additions,  changes, 
deletions)  to  the  baseline  could  be  easily  tracked  between  the  user  and  the  producer,  and  the  results 
would  provide  meaningful  input  to  DMA’s  Digital  Production  System  (DPS)  effort.  At  the  time 
the  CATSS  Requirements  Data  Base  was  established,  a  snapshot  of  the  MARK  90  RFC  E20-01 1 
Data  Base  (defined  by  the  Section  100  Glossary)  was  used  to  establish  the  “data  content”  baseline; 
i.e.,  features,  attributes,  and  associated  definitions  according  to  the  Feature  Attribute  Coding 
Standard  (FACS).  As  applicable,  the  various  product  specifications  were  referenced  by  Air  Force 
users  to  derive  feature  selection/inclusion  conditions.  These  product  specifications  are  also  MARK 
90  editions.  When  a  system  specified  additional  features  or  attributes,  they  were  extracted  from 
DMA’s  more  recent  RFC  E20-012  and  E20-013  glossaries  to  update  the  CATSS  baseline. 
CATSS-uniquc  features  and  attributes  were  generated  only  when  a  suitable  definition  could  not  be 
located  in  one  of  the  MARK  90  glossaries. 

The  FY88  CATSS  digital  cartographic  data  (DCD)  requirements  analysis  survey  was 
jointly  developed  and  performed  by  cognizant  representatives  from  RL/IRRP,  DMASC,  and  PAR 
Government  Systems  Corporation.  It  was  conducted  using  a  phased  approach.  The  Level  I 
survey  was  designed  to  gather  a  comprehensive,  multiple-dimension  view  of  Air  Force-wide  DCD 
requirements.  The  Level  II  survey,  conducted  at  the  user  sites,  was  designed  to  collect  detailed 
DCD  content  requirements.  Information  obtained  from  the  Level  I  surveys  was  analyzed  to 
categorize  and  prioritize  systems  requirements  for  DCD  and  to  identify  candidates  for  the  Level  II 
survey. 

The  Level  I  survey  solicited  the  following  types  of  information  from  USAF  programs  and 
systems: 

•  System  Mission  Areas 

•  Primary  and  Subordinate  Functions  Requiring  DCD 

•  System  Acquisition/Development  Status 

•  Supported  Weapon  Systems/Technology  Areas 

•  Sensors  Employed  and  Accuracies 

•  System  Level  Accuracy  Requirements 

•  Current  or  Planned  Usage  of  DMA  MC&G  Products 

•  DCD  Accuracy  and  Resolution  Requirements 
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•  Data  Structures,  Formats,  Transfer  Media,  and  Update  Requirements 

•  Cartographic  Data  Categories  Required  (i.e„  Feature  Data,  Vertical  Obstructions, 
Terrain  Elevation  Data,  Navigational  Aids/Aeronautical  Data,  Geopositional  Data, 
Reference  Scenes,  Gravity,  Magnetic  Data,  and  Other  Data) 


A  total  of  242  Air  Force  system  users  were  formally  solicited  by  mail  via  the  Level  I  survey  form; 
nearly  one-half  (114)  of  all  solicited  systems  returned  a  completed  Level  I  survey.  It  was 
presumed  that  those  systems  not  responding  to  the  survey  either  had  no  current  or  future  DCD 
requirements  or  could  not  specify  requirements  at  that  point  in  time.  Of  the  114  responses, 
fourteen  (14)  could  not  be  used  because  they  were  not  substantive. in  content.  Each  of  the 
remaining  100  systems  surveyed,  as  well  as  additional  systems  identified  as  a  result  of  Level  I 
survey  responses  (for  a  total  of  109  systems),  was  evaluated  for  significance  of  need  for  digital 
cartographic  data.  A  DCD  rating  of  1  to  7  was  assigned  to  each  system  as  follows; 


Evaluation  Criteria 

PCD  Rating 

Number  of  Svstems 

Driver  -  system  has  significant  near-term 
requirement 

1 

24 

Potendal  Driver  -  system  has  significant 
future  DCD  requirement 

2 

16 

Moderate  -  system  has  requirement  for 

DCD  improvements 

3 

16 

Low  -  system  has  low-level  usage  of  DCD 
and  is  generally  satisfied 

4 

12 

Tracking  -  New  Program,  R&D  stage  of 
development  and  far-term/undefined  DCD 
requirement 

5 

18 

Possible  Tracking  -  Insufficient  survey 
data  or  satisfied  (no  new  DCD  requirements) 

6 

15 

Beyond  Scope  -  Non-USAF,  Program 
Cancelled,  or  Simulator/Training  System 

7 

8 

Other  factors  that  influenced  assignment  of  the  DCD  Rating  included:  current  or  planned  usage  of 
DCD,  whether  or  not  existing  DMA  products  would  satisfy  system  requirements,  stage  of  system 
development/operational  status,  system  user’s  knowledge  of  DCD  requirements,  and  funding 
support  for  system  development/maintenance. 
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After  reviewing  and  analyzing  the  initial  survey  responses,  a  second  and  more  detailed 
survey  form  was  developed  to  collect  specific  cartographic  feature  data  requirements  for  Air  Force 
systems  designated  as  having  significant  requirements.  Forty-four  (44)  systems  that  have 
substantive  and/or  representative  requirements  were  identified  as  “drivers”  or  “potential  drivers” 
through  analysis  of  the  Level  I  survey  results;  then  the  point-of-contact  for  each  of  these  systems 
was  contacted  for  a  follow-up  site  visit.  In  some  cases,  multiple  site  visits  were  required.  CATSS 
team  members  interviewed  system  representatives  on  site  to  clarify  Level  I  survey  responses  and  to 
compile  information  for  the  Level  II  survey  form.  The  Level  II  site  surveys  were  performed 
during  the  May  through  August  1988  time  frame. 

The  Level  II  survey  involved  jointly  filling  out  a  cartographic  feature-attribute-function 
worksheet  for  each  required  cartographic  feature.  A  glossary  of  feature  descriptors/attributes  was 
used  to  aid  this  activity.  Relevant  documents  pertaining  to  DCD  requirements  and  cartographic 
functions  within  the  context  of  the  USAF  systems  surveyed  were  also  collected  during  the  Level  II 
site  visits.  Not  all  system  requirements  could  be  represented  at  the  same  level  of  information. 
Twenty-six  (26)  of  forty-four  (44)  system  descriptions  provided  the  detailed  feature/attribute 
information  required  to  generate  the  Feature/Attributes  Requirements  Table  (reference  Volume  II, 
Section  300,  Table  300-1  of  the  USAF  DCD  Product  Specification). 

3.2  REQUIREMENTS  DATA  BASE 
3.2.1  Purpose 

The  purpose  of  the  CATSS  Requirements  Data  Base  was  to  organize  and  maintain  the 
information  contained  in  each  survey  form  with  minimal  interpretation.  The  intent  was  to  capture 
the  data  in  as  close  to  “raw”  form  as  possible  and  to  keep  the  activity  of  reducing/summarizing  data 
and  the  drawing  of  conclusions  completely  separate  from  the  data  basing  activity.  The  CATSS 
Requirements  Data  Base  contains  survey  data  for  109  systems  and  includes  (as  a  minimum)  a 
system  description  for  each  system  or  technology  area  defined.  Detailed  feature-attribute-function 
information  was  collected  and  stored  in  the  data  base  for  twenty-six  (26)  of  the  forty-four  (44) 
systems  surveyed  on  site.  Software  was  developed  to  generate  detailed  reports,  interim  data  reduc¬ 
tion  reports,  and  high-level  summary  reports.  The  majority  of  reports  included  in  the  USAF  DCD 
Product  Specification  were  generated  directly  from  the  data  base,  using  report  generator  software. 
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3.2.2  Data  Base  Structure 


The  CATSS  Requirements  Data  Base  was  developed  on  a  VAX  system  operating  under 
Ultrix  using  the  Informix  relational  data  base  management  system.  Informix  tools  were  used  to 
develop  forms/menus  to  support  the  process  of  data  entry  and  data  entry  verification.  Informix 
4GL  report  generator  programs  and  report  programs  were  written  to  provide  repons  and 
(additionally)  to  verify  data  base  content.  Figure  3-1  depicts  the  CATSS  Requirements  Data  Base 
structure.  As  shown,  the  cat_system  table  is  the  parent  (root)  table.  Each  entry  contains  the 
system  acronym,  name,  description,  development  phase,  date  information  was  received,  and  the 
DCD  priority  rating  of  1  to  7.  Fifteen  (15)  tables  are  directly  linked  to  it  via  the  unique  numeric 
sys_id  key: 

•  cat_sys_poc  -  Each  entry  defines  a  US  AF  system  point-of-contact  (POC).  Multiple 
cat3ys_Ip°c  entries  may  be  linked  to  a  cat_system  entry. 

•  cat_sys_product  -  Each  entry  contains  information  about  a  specific  product  with 
reference  to  its  use  by  the  system:  current  vs.  planned  use,  used  to  generate  digital 
data,  used  to  audit  other  products,  product  satisfaction,  if  not  satisfied  -  deficiency 
flags  include:  feature  content,  attribute  content,  area  of  coverage,  accuracy, 
density/resolution,  structurc/format,  portability,  media,  storage/compression 
techniques,  quality,  currency,  and  compatibility  with  other  products. 

•  cat_related_sys  -  Each  entry  allows  definition  of  a  system’s  relationship  with 
another  system.  It  can  be  used,  for  example,  to  link  multiple  subsystems  to  a  system. 

•  cat_sys_mission  -  Each  entry  defines  a  single  mission  supported  by  the  system. 

•  cat_sys_sensor  -  Each  entry  defines  a  single  sensor  type  employed  by  the  system. 

•  cat_sys_weapon  -  Each  entry  defines  a  single  weapon  type  employed  by  the  system. 

•  cat  sys_acc  -  Each  entry  defines  the  stated  system  accuracy,  units  of  measure,  error 
probability,  and  accuracy  text.  Usually,  only  one  entry  is  associated  with  a  specific 
system. 

•  catTjsys_datum  -  Each  entry  defines  a  single  datum  the  system  uses.  Forty-two 
horizontal  datums  and  nineteen  vertical  datums  are  defined.  Therefore,  if  all  datums 
were  used  (unlikely),  a  system  could  possible  have  sixty-one  (62)  entries  associated 
with  it. 

•  cat  sys_area  -  Each  entry  defines  a  codified  geographic  area  of  the  world  where 
DCl)  is  required.  Flag  fields  indicate  whether  the  area  is  test  and/or  operational.  Fiscal 
year  and  quarter  required  (e.g.,  90-3)  and  free  text  are  also  provided. 

•  cat_dcd_acc  -  Each  entry  allows  entry  of  absolute  and  relative  horizontal  and  vertical 
accuracies  with  a  common  unit  of  measure  (e.g.,  m  -  meters)  and  free  text  for  absolute, 
relative,  and  overall  accuracy. 
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Figure  3-1.  CATSS  Requirements  Data  Base  Structure 


•  cat  dcd  res  —  Each  entry  allows  inclusion  of  minimum  ground  distance  and  area 
minimum  length  and  width  for  feature  capture,  minimum  post  spacing  if  matrix  data, 
the  common  unit  of  measure,  and  free  text. 

•  cat  dcd  struct  —  Each  entry  contains  information  concerning  a  DCD  file  structure 
maintained  by  the  system  in  question.  Flags  indicate  whether  the  data  is  generalized 
and/or  compressed;  whether  the  format  is  matrix,  raster,  topological  vector,  spaghetti 
vector,  or  other,  and  whether  near-real-time  update  is  required.  A  text  field  is  also 
provided. 

•  cat_dcd_nrt  -  Each  entry  indicates  the  feature  (fcode),  function,  access  mode 
(location,  fcode,  attribute,  and/or  other  method),  and  text  concerning  near-real-time 
(NRT)  update  requirements. 

•  cat_fcode_func  -  Each  entry  identifies  a  feature  (fcode)  and  associated  function.  It 
is  a  table  in  its  own  right,  but  also  provides  the  link  to  five  MARK  90  DPS  Data  Base 
tables,  which  in  turn  provide  definition  of  each  feature,  its  attributes  and  attribute 
values,  and  the  conditions  under  which  the  feature  will  be  selected. 

•  cat  sys_ref  -  Each  entry  identifies  a  reference  document  that  supports  requirements 
of  tKe  associated  system.  Information  includes  title,  author,  date,  security 
classification,  and  availability. 

The  five  tables  outlined  in  bold  on  the  right  side  of  Figure  3-1  represent  the  MARK  90 
Section  100  Glossary  plus  amendments/additions  as  result  of  the  CATSS  requirements  survey. 
These  tables  define  each  feature,  its  associated  attributes  and  attribute  values,  and  zero-to-many 
conditions  for  inclusion  in  the  US  AF  DCD  Product  Specification. 

The  eight  tables  at  the  bottom  of  Figure  3-1,  labeled:  category,  cat_datum, 
cat_function,  cat_geo_code,  catmission,  cat_phase,  cat_prod_id,  and  cat_sensor_id 
provide  code-to-name  conversions  for  report  generation  purposes. 


3.3  DCD  PRODUCT  SPECIFICATION 
3.3.1  Product  Specification  Content 

The  USAF  DCD  Product  Specification  reflects  the  requirements  gathered  by  the  CATSS 
survey  team.  These  requirements  were  collected  at  various  levels  of  detail.  For  a  majority  of  the 
systems  surveyed,  it  provides  system/technology  characterization  in  terms  of:  mission  areas, 
cartographic  functions  supported,  usage  of  DMA  products,  and  weapon  systems  and  sensor 
systems  employed.  These  reports  may  be  found  in  Volume  I,  Appendix  A  (if  classified)  or  in 
Volume  III  (if  unclassified).  Detailed  feature/attribute  requirements  were  processed  and  reported  in 
Table  300-1  for  the  systems  that  were  able  to  provide  such  detail.  Table  300-1  and  supporting 
dictionaries  are  contained  in  Volume  II  of  the  USAF  DCD  Product  Specification.  Appendices  B 
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and  C  contain  special  DCD  requirements  reports:  “DCD  Requirements  for  the  Special  Operations 
Forces  Aircrew  Training  System  (SOF  ATS)"  and  “DCD  Requirements  for  Geodetic  and 
Geophysical  Data,”  respectively.  We  felt  that  the  SOF  ATS  requirements  uncovered  by  the 
CATSS  survey  should  be  documented  even  though  they  specifically  fall  under  Project  2851  and 
could  not  be  included  with  the  requirements  of  non-training,  non-simulator  systems.  Geodetic  and 
geophysical  data  was  reported  separately  because  the  information  collected  was  different  in  nature 
and  could  not  be  tabulated  or  summarized  properly  using  the  summary  and  reporting  tools 
developed  to  report  cartographic  feature  data  requirements. 

3.3.2  Summary  of  Findings 

The  following  paragraphs  provide  a  brief  highlight  of  trends  and  areas  of  concern  that 
surfaced  as  result  of  the  CATSS  survey  effort 

Increasing  Need  for  Digital  Data 

The  Air  Force  requirement  for  detailed  digital  cartographic  data  is  expanding  at  a  tremen¬ 
dous  pace.  This  is  due  to  the  increasing  number  of  systems  under  development  or  operationally 
fielded  and  to  the  increasing  and  diverse  uses  of  DCD  to  support  system  mission  areas.  The 
growth  rate  of  digital  prototype  products  continues  to  soar  as  system  developers  define  new 
requirements  or  amend  existing  product  requirements  to  address  mission  support.  Diversification, 
rather  than  commonization  of  requirements  to  serve  multiple  using  systems,  has  all  too  clearly  been 
the  modus  operandi.  Many  systems  currently  perform  extensive  data  transformations  and 
reformatting  (including  use  of  hardcopy  products  to  generate  digital  products)  in  order  to  conform 
to  their  unique  data  models  -  possibly  causing  inadvertent  data  degradation,  as  well  as  delays  in 
operational  readiness.  These  problems  were  noted  for  many  of  the  USAF  systems  surveyed. 
Reconnaissance/strike  systems  and  systems  with  a  requirement  to  perform  real-world  mission 
rehearsals  would  be  most  severely  impacted  by  data  degradation  and  processing  delays. 

Interoperability  a  Must 

Interoperability  of  the  digital  data  among  systems,  as  well  as  among  the  Services,  is 
needed.  This  will  relieve  the  impact  on  DMA  of  producing  many  differing  products  and  also 
simplify  the  update  cycle.  In  order  to  be  effective,  inter-  and  intra-Service  systems,  such  as  the 
Joint  Surveillance  and  Target  Attack  Radar  System  (Joint  STARS)  and  the  Mission  Support 
System  (MSS),  must  work  from  a  common  view  of  the  world.  Data  source,  content,  format,  and 
update  cycle  need  to  be  compatible,  if  not  the  same.  The  proliferation  of  system-specific  digital 
cartographic  data  bases  resulting  from  digitization  of  hardcopy  products  by  individual  Air  Force 


system  developers  is  counterproductive  in  many  ways.  It  expends  large  amounts  of  system 
personnel  time  and  monetary  resources  that  could  be  used  in  better  ways;  it  directly  counters  the 
requirement  for  inter-Service  operability;  and  it  continues  to  extend  the  need  for  and  ineffective  use 
of  hardcopy  products  when  digital  products  are  required. 

Feature  Data  Structure 

The  definition  and  implementation  of  a  logical  structure  for  digital  cartographic  data  is 
required  in  order  to  support  interoperability  and  to  eliminate  redundancy.  As  revealed  by  many  of 
the  surveys,  the  logical  structure  supporting  feature  topology  is  required.  That  is,  for  each  feature, 
spatial  relationships  of  features  that  are  touching/adjacent  on  the  same  theme  or  overlay,  or  above 
or  below  on  different  themes  or  overlays  must  be  maintained.  The  completed  surveys  also 
revealed  the  need  for  data  currency  and  the  requirement  for  near-real-time  (NRT)  updates  of 
individual  features,  as  well  as  the  need  for  periodic  feature  updates  in  the  form  of  “changes”  from 
the  producing  agency.  When  the  logical  structure  for  feature  data  is  defined,  it  should  be  able  to 
support  the  requirements  for  both  update  modes. 

Terrain  Elevation  Data  Structure 

Systems  surveyed  expressed  certain  structure  preferences  for  digital  terrain  elevation  data  in 
matrix  format  (e.g.,  DTED  Levels  1  and  2).  Standard  interval  post  spacing  is  preferred  to  the 
current  variable  post  spacing  dependent  on  latitude.  Those  systems  using  DTED  for  display  with 
imagery  requested  that  the  origin  be  changed  from  the  southwest  comer  to  the  northwest  comer  to 
avoid  the  need  for  origin  adjustment  Systems  using  DTED  in  concert  with  cartographic  feature 
data  do  not  want  the  origin  changed,  however. 

Exchange  Format  Considerations 

Since  detailed  investigations  to  define  a  standard  exchange  format  are  currently  being 
performed  by  the  U.S.  Geological  Survey  (USGS),  specific  format  recommendations  are  inappro¬ 
priate.  The  following  is  a  list,  however,  of  desired  specifications  which  we  believe  any  exchange 
format  should  include.  In  many  cases,  the  recommendation  applies  equally  to  specifications  for  a 
logical  structure  that  can  be  derived  from  the  data  encoded  in  the  exchange  format: 

•  Format  allows  for  recording  of  feature  topology  (the  spatial  relationship  of  features 
with  other  related  features  on  the  same  or  different  planes). 

•  Format  includes  entities  and  relationships  that  will  allow  data  access  by  location 
(coordinates),  by  segment  (or  face),  by  feature  ID  (unique  key),  by  feature  code 
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(i.e.,  FACS  code),  by  feature  representation  type  (area,  line,  or  point),  by  feature 
descriptors  (attributes),  or  by  some  combination  of  one  or  more  of  these  items. 

•  Format  supports  modification  (addition,  update,  deletion)  of  individual  features  or 
feature  groups  using  the  access  methods  listed  above. 

•  Format  allows  for  a  variable  number  of  descriptors  (attributes)  per  feature. 

•  Format  provides  a  method  to  define  real-world  representations  of  features  comprised  of 
component  features  (e.g.,  river/stream  defined  by  river/stream  left  bank  and  river/ 
stream  right  bank  component  features,  or  defined  by  river/stream  centerline  component 
feature)  without  being  redundant. 

•  Format  allows  for  locational  data  (points)  to  be  optionally  recorded  in  two  dimensions 
(x,y)  or  three  dimensions  (x,y,z). 

•  Format  supports  recording  of  different  coordinate  systems  (Cartesian  or  geographic). 

•  Data  encoding  and  field  sizes  are  transportable  and  conform  to  an  agreed-upon 
standard. 

•  A  variety  of  units  of  measure  (e.g.,  feet,  meters,  centimeters,  nautical  miles,  etc.)  and 
units  of  precision  (e.g.,  n.n,  n.nn,  n.nnn,  etc.)  is  supported. 

•  Format  allows  for  the  recording  of  data  quality,  including:  data  sources,  positional 
accuracy,  accuracy  of  attribution,  logical  consistency,  and  completeness  of  the  data. 
Information  may  need  to  be  recorded  for  the  entire  map  sheet  area  or  for  sub-areas  or 
“tiles.” 

Accuracy.  Resolution.  Consistency.  Feature/Attribute  Detail,  and  Coverage 

Both  tactical  and  strategic  requirements  for  digital  cartographic  data  are  more  stringent  than 
ever  before.  The  completed  surveys  indicate  a  need  for  enhanced  accuracy,  resolution,  detail,  and 
consistency  among  data  types  and  products.  Attribution  requirements  for  both  cultural  and  natural 
features  are  quite  extensive  (as  defined  in  Volume  II,  Section  300  of  the  USAF  DCD  Product 
Specification).  As  stated  in  many  of  the  completed  surveys,  digital  data  required  to  support  Air 
Force  systems  should  not  be  constrained  by  hardcopy  production  requirements.  Although  back¬ 
ground  display  is  an  important  function,  it  is  only  one  of  many  important  uses  of  DCD  in  the  syn¬ 
thesizing  of  multi-source  data  into  intelligence.  Two  new  requirement  for  detailed  digital  carto¬ 
graphic  data  surfaced  during  the  CATSS  survey.  First,  accurate  and  detailed  digital  cartographic 
data  is  required  for  a  radius  of  up  to  60  nautical  miles  for  all  operational  and  contingency  air  bases 
worldwide,  including  CONUS.  Second,  detailed  railroad  data  is  needed  within  CONUS  in 
support  of  strategic  systems.  Heretofore,  requirements  for  only  training  areas  within  CONUS 
have  been  documented.  It  can  be  expected  that  such  requirements  will  increase  as  defensive  sys¬ 
tems  and  mobile  offensive  systems  become  operational  and  expand  in  scope  and  number. 
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Early  PCD  Requirements  Definition 


The  CATSS  survey  highlighted  the  fact  that  detailed  cartographic  requirements  must  be 
defined  early  in  the  life  cycle  of  the  program.  Previously,  the  tendency  has  been  to  proceed  well 
into  the  development  cycle  and  then  to  formally  surface  the  need  for  digital  cartographic  data. 
Thus,  in  many  cases,  by  the  time  DMA  is  given  the  requirement,  the  need  is  critical  and  the  time 
given  to  respond  is  insufficient.  Many  of  the  problems  summarized  above  have  been  recognized 
and  addressed  through  use  of  Air  Force  Form  AFR  96-9,  “Request. for  MC&G  Support,”  in 
accordance  with  Regulation  AFR  96-9.  The  Digital  Production  System  now  under  development  by 
DMA  will  help  to  solve  many  of  these  issues.  DMA  can  only  address  the  requirements  they  know 
about,  however.  The  task  of  surfacing  and  organizing/unifying  requirements  for  presentation  to 
DMA  is  required  of  each  Service.  Within  the  Air  Force,  RL/IRRP  has  been  assigned  technical 
responsibility  for  this  task  and  will  continue  to  monitor  Air  Force  requirements  for  digital 
cartographic  data.  For  example,  the  eighteen  systems  given  a  DCD  rating  of  “tracking”  and  the 
fifteen  systems  given  a  rating  of  “possible  tracking”  should  be  contacted  periodically  to  ensure  that 
additional  requirements  (as  they  surface)  are  folded  into  the  portfolio  of  unified  USAF  digital 
cartographic  data  requirements. 
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4.  CATSS  LABORATORY  DATA  BASE  SYSTEM 


This  section  presents  the  functional,  hardware,  and  software  characteristics  of  the  DBS 
laboratory  system.  Specifically,  Section  4. 1  examines  the  purpose  of  the  laboratory  system  and 
factors  driving  the  functional  requirements  of  the  DBS.  Section  4.2  describes  the  hardware 
platform  of  the  DBS.  Section  4.3  summarizes  the  DBS  data  base  design  and  structure.  Finally, 
Section  4.4  provides  a  concise  description  of  DBS  system  functionality  and  operational 
characteristics. 

4.1  PURPOSE  OF  LABORATORY  SYSTEM 

The  goal  of  the  CATSS  DBS  was  to  provide  a  laboratory  system  for  the  integration  and 
manipulation  of  digital  cartographic  data  products  which  would  support  the  evaluation  and 
technical  definition  of  USAF  requirements  for  digital  cartographic  data  content  and  structure(s). 
The  approach  to  this  goal  was  to  establish  a  laboratory  capability  to  load  and  create  data 
structures/formats  required  to  support  the  emulation  and  demonstration  of  representative  weapon 
system  functions,  applications,  and  algorithms. 

The  required  capabilities  of  the  DBS  can  be  summarized  as  follows: 

•  Interface  to  Digital  Cartographic  Data  Applications:  this  interface  will  provide  the 
requisite  data  to  the  laboratory  digital  data  applications  including  the  Digital 
Cartographic  Applications  Segment  and  the  Sensitivity  Modeling  Segment.  These 
applications  will  require  a  variety  of  digital  data  for  testing  and  demonstrations.  Two 
levels  of  data  access  will  be  required: 

File  Level:  consisting  of  selected  data  content/structure  which  has  been  specially 
prepared  based  on  parameters  such  as  AOI,  feature  content,  or  format 

Feature  Level:  consisting  of  specifically  requested  feature  information  for  inter¬ 
active  or  near-real- time  applications  based  on  transaction  query  parameters  such 
as  data  set  feature  type,  location,  etc. 

•  Interactive  Query  of  Geographic  Information:  the  DBS  is  intended  to  provide  basic 
facts,  as  well  as  derived' geographic  feature  and  terrain  information.  The  derived 
information  is  intenefed  to  include  inferences  which  can  be  gleaned  through  relational, 
spatial,  or  boolean  processing.  This  capability  will  be  serviced  by  a  combination  of 
standard  .and  ad  hoc  forms  of  query  processing. 
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Other  capability  requirements  and  technical  factors  considered  in  the  functional  scoping  of 
the  DBS  include: 

•  Digital  Cartographic  Data  Requirements: 

Data  Types  -  a  growing  need  exists  to  store/access  multiple  types  of  data,  including 
cartographic,  terrain,  imagery,  intelligence,  weather,  etc. 

Cartographic  Feature  Content  -  applications  require  various  kinds  content  such  as 
depth/level  of  feature  categories/types,  feature  detail,  and  attribution. 

Formats  and  Reference  Systems  -  standard  vs.  special  data  formats,  internal  vs. 
user’s  requirements  for  geographic  reference  frames. 

Structure  -  display  data,  topology,  network,  matrix. 

Coverage  -  geographic  extent,  ‘seamless’  data  sets. 

Quality  -  general  data  verification,  data  degradation  required  to  support  sensitivity 
modeling. 

•  Evolution  of  the  Digital  Data  Production  Program:  The  primary  supplier  of  digital 
cartographic  data  is  the  Defense  Mapping  Agency.  The  standard  digital  data  available 
today  is  represented  principally  by  the  DLMS  program,  although  the  DMA  is  in  the 
middle  of  a  major  modernization  program  which  will  result  in  substantial  changes.  The 
DBS  will  thus  need  to  take  advantage  of  current/near-term  digital  data  and,  at  the  same 
time,  accommodate  strategies  for  using  the  more  comprehensive  future  data  base. 
Considerations  should  include  the  benefits  of  a  special  USAF  extract  from  the  master 
DMA  digital  feature  data  base,  as  well  as  the  potential  utility  of  alternate  formats/media 
such  as  represented  by  the  evolving  Map/Chan  CD-ROM  program. 

•  Data  Base  Updates  and  Currency:  The  need  exists  to  provide  direct  updates  to  DBS  on¬ 
line  data  that  emulate  field  updates  of  selected  features  due  to  military  operations,  such 
as  the  destruction  of  transportation  features  which  would  substantially  impact  applica¬ 
tions  such  as  predictions  of  vehicle  routing. 

•  Potential  Application  of  CATSS  GIS/RDBMS  Technology:  A  key  issue  was  the 
emphasis  placed  on  the  DBS  as  an  interactive/ad  hoc  query  information  system. 
Presently,  our  perception  is  that  the  USAF  laboratory  should  be  striving  for  new  data 
base  concepts  and  technology  which  can  be  used  in  multiple  roles:  1)  as  a  geographic 
information  system  that  demonstrates  the  utility  of  interactive  spatial  queries;  and  2)  as  a 
supplier  of  specialized  data  formats  to  applications  software  and  external  systems. 
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4.2  SYSTEM  CONFIGURATION 


The  CATSS  Data  Base  System  is  configured  on  a  Sun  3/60  workstation  and  VAX  8350, 
connected  via  ethemet,  The  VAX  8350  consists  of  32  megabytes  of  memory,  the  VAX/VMS  4.6 
operating  system,  and  FORTRAN  (version  4.7)  and  c  (version  2.3)  compilers.  The  GFE  Sun 
3/60  consists  of  8  megabytes  of  memory,  the  UNIX  (BSD  4.2)  operating  system,  c  compiler,  and 
the  Primc/WILD  System  9  Geographic  Information  System  (version  2.1.1)  and  embedded 
Rodnius  EMPRESS  Relational  Data  Base  Management  System.  The  Sun  3/60  was  upgraded  to 
include  12  megabytes  of  memory  and  a  1.4-gigabyte  removable  disk  drive,  and  was  configured 
with  a  minimum  of  100  megabytes  of  swap  space  for  System  9  operation.  Details  of  the 
equipment  configuration  can  be  found  in  the  CATSS  DBS  Software  Requirements  Specification. 

4.3  DATA  BASE  DESIGN  AND  STRUCTURE 

The  CATSS  DBS  design  was  required  to  maintain  a  master  (worldwide,  integrated) 
holdings  data  base  as  well  as  separate  Temporary  Holdings.  Sources  for  DBS  holdings  varied  in 
complexity,  format,  content,  and  data  representation  (e.g.,  TTD/Mini-Topo,  DLMS/DFAD,  vector 
cartographic,  textual  or  raster).  The  DBS  also  required  a  rather  extensive  set  of  functionality  which 
would  allow  this  data  to  be  manipulated  in  various  ways.  The  System  9  GIS,  designed  with  the 
intent  to  handle  large,  seamless  databases,  was  selected  as  the  core  for  development  because  it  was 
the  only  commercially  available  GIS  (at  that  time)  that  could  accommodate  an  integrated,  3D, 
topological  data  structure  (such  as  TTD/Mini-Topo). 

However,  although  it  exhibits  obvious  good  qualities.  System  9  does  use  some  internal 
structuring  and  data  organization  techniques  that  constrain  the  storage  and  manipulation  of  very 
large  databases,  such  as  the  CATSS  DBS.  System  9  specifically  requires  that  all  related  data  be 
collectively  contained  within  a  single  master  data  base,  referred  to  as  a  project  data  base.  In 
System  9  parlance,  a  partition  is  a  working  copy  of  a  subset  of  a  project;  the  subset  is  defined  by 
both  AOI  and  featurc/data  content.  The  ATB_viewer,  a  System  9-related  prototype  product,  which 
provides  a  basic  toolbox  of  utilities  (commands)  to  access  and  display  partition  data,  and 
underlying  software  libraries,  such  as  the  object  and  menu  handlers,  provides  for  customized 
development  of  functionality  not  readily  available  under  the  standard  System  9  implementation. 

Initial  evaluation  of  the  practicality  of  implementing  the  global  CATSS  data  base  within  a 
miosis  System  9  project  data  base  surfaced  the  following  challenges: 

•  It  was  estimated  that  even  a  nominally  populated  global  data  base  would  not  entirely  fit 

on  the  available  on-line  disks. 
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•  Mechanisms  would  need  to  be  devised  to  keep  track  of  data  base  information  that  is  not 
exclusively  cartographic  in  nature  (weather,  intelligence  reports,  etc.). 

•  Mechanisms  would  need  to  be  devised  to  provide  users  with  access  to  the  availability  of 
data  (overview  of  data  base  holdings)  without  recourse  to  the  data  itself. 

•  It  would  be  difficult  to  maintain  data  integrity  (corrupt  input  data  would  contaminate  the 
entire  data  base,  as  would  problems  occurring  during  the  integration  of  data  from  a 
variety  of  sources). 

•  Archives  would  span  off-line  volumes. 

An  alternative  design  solution  involved  implementing  the  global  CATSS  data  base  within 
multiple  System  9  project  databases  over  noncontiguous  data  areas  (such  as  designated  test  areas). 
This  alternative  was  also  discarded  due  to  the  following  constraints: 

•  Multiple  definitions  of  the  large  data  base  schema  would  be  difficult  to  update/maintain. 

•  Future  overlap  of  areas  of  interest  between  projects  becomes  awkward. 

•  Overview  of  separate  projects  becomes  a  logistical  nightmare. 

•  Addition/integration  of  data  becomes  project-specific. 

•  References  to  noncartographic  data  must  be  maintained  in  each  project. 

An  evaluation  of  the  above  design  considerations  made  it  apparent  that  the  DBS  data  base 
needed  to  be  tiled  (split  up)  into  manageable  pieces.  This  design  required  the  management  of  two 
layers  of  information  or  data.  The  first  layer  is  represented  by  the  meta-feature  data  describing  all 
holdings  within  the  DBS.  The  second  data  layer  is  represented  by  the  contents  of  individual  tiles 
of  data  (not  directly  accessed  by  the  user)  and  Temporary  Holding  partitions  (data  which  the  user 
may  display  and  manipulate).  This  design  was  implemented  using  a  System  9  project  data  base  as 
a  “phantom”  global  data  base;  this  global  data  base  provides  a  single  master  schema  definition,  but 
never  contains  any  data.  Characteristics  of  this  design  are  highlighted  below: 

•  The  project  data  base  serves  as  the  master  schema  definition  and  contains  no  data  (is  a 
“phantom”  project). 

•  A  special  partition  exists  that  describes  the  actual  data  base  holdings. 

•  The  master  data  base  (actual  data)  exists  as  tile  partitions  of  the  “phantom”  project. 

•  Temporary  copies  of  the  “phantom”  are  created  and  used  to  manipulate  data  in  tiles  and 
user  partitions. 

The  benefits  realized  from  this  “phantom”  project  design  are: 

•  No  data  exists  in  the  project  itself,  minimizing  use  of  on-line  resources. 

•  Master  data  exists  only  in  Tiles. 
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•  The  schema  definition  and  System  9-specific  information  reside  in  a  single  data  base 
(feature  and  attribute  definitions,  graphic  transforms,  theme  definitions,  etc.). 

•  Master  data  base  (tiles)  need  not  be  on  line,  except  for  EXTRACT  and  ADD 
functionality. 

•  Master  data  base  can  be  archived  in  single  tiles  and  user  partitions  and  brought  in  as 
needed. 

•  “Phantom”  project  simplifies  manipulation  of  user  environment  variables. 

•  “Phantom”  project  unifies/generalizes  overview  of  all  data  base  holdings. 

•  “Phantom”  project  permits  arbitrary  definitions  of  AOIs. 

•  “Phantom”  project  allows  combination/sectioning  of  AOIs  without  master  data. 

•  Master  “phantom”  project  (and  data  base)  is  not  corrupted  by  addition  of  new  data  to 
copy. 

This  design  concept  is  diagrammed  in  Figure  4-1,  “CATSS  DBS  Software-Data  Base 
Hierarchy.”  This  figures  shows  that  the  Global  Project,  Temporary  Copy  of  the  Global  Project, 
and  Tile  Partitions  arc  accessed  and  maintained  through  the  DBS  ATB_viewer  and  customized 
software,  but  the  contents  of  these  projects/partitions  are  never  directly  viewed  by  the  user.  The 
Database  Holdings  Partition,  however,  is  accessed  and  maintained,  and  its  contents  are  displayed 
for  the  user  through  the  DBS  ATB_viewer.  Temporary  Holdings  Partitions  are  accessed  and 
maintained  through  both  the  DBS  ATB_viewer  and  System  9;  however,  the  contents  of  these 
holdings  arc  displayed  (and  edited)  only  through  the  System  9  Data  Capture  and  Edit  utility  (DCE) 
which  is  activated  by  the  DBS  ATB_viewer.  Each  of  these  major  components  of  the  CATSS  DBS 
data  base  design  is  described  in  further  detail  below: 

Global  Project:  The  CATSS  DBS  implementation  uses  one  System  9  project  data  base  (the 
Global  Project)  to  serve  exclusively  as  the  schema  definition  for  all  CATSS  DBS  data, 
the  source  of  the  Database  Holdings  Partition,  and  controller  for  data  integrity  in  master/ 
temporary  holdings.  This  project  data  base  has  worldwide  extent  and  contains  all 
System-9-specific  CATSS  theme  (filter)  definitions,  data  representation  characteristics 
(geographic  latitude/longitude  in  thousandths  of  arc  seconds),  and  symbology  for  display 
purposes.  It  contains  no  actual  data,  but  simply  serves  as  a  template  for  the  manipulation 
of  actual  data  defined  in  the  Database  Holdings  Partition  and  contained  in  the  Tile 
Partitions  and  Temporary  Holdings  Partitions,  described  below. 

Database  Holdings  Partition:  The  Database  Holdings  Partition  is  a  special  partition  of  the 
Global  Project  which  is  used  by  the  CATSS  DBS  to  identify  all  holdings  (master  and 
temporary,  vector  and  nonvector)  of  the  DBS.  This  partition  data  base  contains  all  meta¬ 
data  describing  all  data  holdings  of  the  CATSS  DBS;  it  does  not  contain  any  other  actual 
source,  tile,  or  temporary  holding  data.  The  contents  of  this  worldwide  extent  partition 
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are  directly  displayed  to  the  user  in  the  Overview  Graphics  Window  under  the  CATSS 
DBS  ATB_viewer  interface.  To  provide  a  visual  point  of  reference  for  the  user,  this 
partition  also  contains  WDB  II  data  which  was  directly  loaded  into  it  for  use  as  a 
background  on  displays. 

The  following  meta-data  is  contained  within  the  Database  Holdings  Partition: 

•  Tile  boundary  meta-features  are  used  to  refer  to  the  actual  tiles  of  data  contained 
within  DBS  master  holdings  (Tile  Partitions). 

•  Temporary  holding  meta-features  are  used  to  refer  to  the  actual  data  contained 
within  Temporary  Holdings  Partitions. 

•  Source  data  meta-features  generally  refer  to  data  that  came  from  an  external 
format  and  is  now  stored  (wholly  or  partially)  in  either  Temporary  Holdings 
Partidons  or  Tile  Parudons.  Source  data  meta-features  may  also  refer  to  data 
that  is  off-line  or  nonvector  in  nature  (disallowing  it  from  being  represented  in 
Tile/Temporary  Holdings  Partitions).  Various  source  data  meta-feature  types 
exist  within  the  DBS,  including  TTD,  DTED,  DFAD,  etc.  Actual  feature  data 
contained  within  Tile/Temporary  Holdings  Partitions  are  also  attributed  under 
the  DBS  to  identify  the  source  data  meta-feature  they  were  derived  from, 
providing  a  feature  history  trail. 

Temporary  Copy  of  the  Global  Project:  A  temporary  copy  of  the  Global  Project  is  created 
and  used  as  a  standard  System  9  project  data  base,  specifically  providing  a  copy  of  the 
CATSS  DBS  schema  definition.  Actions  performed  against  data  holdings  require  that  a 
Temporary  Copy  of  the  Global  Project  be  made  so  that  Tile  Partition  data  and  Temporary 
Holding  Partition  data  may  be  manipulated  within  it  to  obtain  the  required  result. 

Tile  Partitions:  Tile  Partitions  arc  used  to  contain  all  vector-type  master  holdings  data  with¬ 
in  the  CATSS  DBS.  There  are  four  basic  types  of  master  holdings:  Textual,  Imagery, 
DTED,  and  vector  data.  The  first  three  types  are  actually  “pseudo”  master  holdings 
because  they  are  stored  as  separate  manuscripts,  in  their  respective  input  formats,  and 
maintained  in  separate  data  directories.  Each  holding  manuscript  is  represented  by  a 
meta-feature  within  the  Database  Holdings  Partition.  Of  these  “pseudo”  master  holdings, 
only  DTED  may  be  converted  to  a  Temporary  Holding  Partition  (vector  format)  for 
further  processing;  however,  due  to  its  volume,  it  is  prohibited  from  being  added  to  the 
real  master  holdings  (Tile  Partitions).  The  fourth  type,  vector  data,  is  maintained  as  a 
global,  seamless  (to  the  user)  master  holdings  data  base.  In  actuality,  because  of  the 
large  data  volumes  and  limited  on-line  storage,  the  master  holdings  are  segmented  into 
non-overlapping  Tile  Partitions. 
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Tile  Partitions  are  used  to  store  the  data  over  spatially  distinct  areas;  however,  master 
holdings  data  is  not  physically  sectioned  on  tile  boundaries.  Data  from  master  holdings 
that  is  wholly  contained  within  a  tile  boundary  will  be  placed  within  the  appropriate  Tile 
Partition.  Master  holdings  data  that  crosses  a  tile  boundary  will  be  replicated  in  all  the 
Tile  Partitions  it  crosses;  data  preparatory  operations  ensure  that  these  replicated  features 
are  recognized  and  handled  properly  to  maintain  data  base  integrity.  In  its  initial 
distribution,  the  CATSS  DBS  master  holdings  is  represented  by  eight  dies,  each  of  which 
is  90  degrees  in  latitude  by  90  degrees  in  longitude.  Each  tile  is  represented  by  a  meta- 
feature  in  the  Database  Holdings  Partition.  Tile  Partitions  are  accessed  and  maintained 
through  the  DBS  ATB_viewer  and  customized  software,  but  the  contents  of  these 
partitions  are  never  directly  viewed  or  manipulated  by  the  user. 

Temporary  Holdings  Partitions:  Temporary  Holdings  Partitions  are  accessed  and 
maintained  through  both  the  DBS  ATB_viewer  and  System  9;  however,  the  contents  of 
these  holdings  are  displayed  and  edited  only  through  the  System  9  Data  Capture  and  Edit 
utility  (DCE)  which  is  activated  by  the  DBS  ATB_viewer.  A  Temporary  Holding 
Partition  is  actually  an  “orphan”  System  9  project/partition  because  although  it  is  a 
complete  and  valid  partition  data  base,  its  project  (Temporary  Copy  of  the  Global  Project) 
is  only  temporarily  created  for  data  manipulations.  Each  Temporary  Holding  Partition  is 
represented  by  a  meta-feature  in  the  Database  Holdings  Partition. 

Data  that  is  not  an  integral  pan  of  master  holdings  (the  actual  Tile  Partition  data)  is 
considered  to  be  a  Temporary  Holding;  this  includes  data  which  is  just  being  added  to  the 
system  (via  digitization,  digital  data  conversion,  or  through  the  applications  interface)  or 
data  which  has  been  extracted  from  master  holdings  for  perusal  or  manipulation. 

All  vector  data  content  (features  and  attributes)  of  the  DBS  is  defined  in  accordance  with  the 
“Defense  Mapping  Agency  (DMA)  Standard  Supporting  Mark  90,  Section  100  Glossary  of 
Feature/Attribute  Definitions.”  This  standard,  DMA’s  Feature  Attribute  Coding  Standard  (FACS), 
defines  a  feature/attribute  hierarchy  ranging  from  a  high-level  feature  category  (feature  grouping)  to 
a  specific  feature  code  with  associated  descriptors  or  attributes.  Within  System  9  /  DBS,  the  spatial 
representation  of  feature  data  is  similar  to  the  TTD/Mini-Topo  structural  definition.  The  System  9  / 
DBS  data  base  structure  supports  a  full  topology,  including  the  representation  of  both  simple  and 
complex  features.  While  complex  features  are  composed  of  one  or  more  simple  features,  each 
simple  feature  has  a  spatial  representation  which  defines  the  feature’s  composition  and  extent  in 
terms  of  surfaces,  lines,  and  nodes.  Figure  4-2,  “System  9  /  DBS  Structure  Diagram,”  provides  a 
conceptual  view  of  these  basic  informational  objects  of  the  System  9  /  DBS  data  base  structure. 
Although  this  diagram  does  not  represent  the  entire  internal  System  9  file  structure,  it  does  provide 
file  and  field  information  pertinent  to  understanding  the  vector  feature  representation  under  DBS. 
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4.4  SYSTEM  FUNCTIONALITY 


The  following  operational  characteristics  provide  orientation  of  how  the  user,  system 
functions,  and  data  interplay  within  the  CATSS  DBS  integrated  system  environment: 

Types  of  DBS  Users:  The  types  of  DBS  users  include  the  DBA/System  Manager,  Analyst, 
and  external  applications.  The  type  of  data,  level  of  access/update,  and  available  resource 
utilization  are  associated  with  the  type  of  user  and  processing  mode. 

Modes  of  Operation:  The  laboratory  DBS  operates  in  one  or  more  of  the  following  general 
modes  or  system  states: 

-  loading  of  external  data  sets  or  archived  data 

-  interactive  processing  in  support  of  ad  hoc  query  or  data  preparation 

-  background  processing  of  pre-defined  ‘batch  mode’  functions 

-  external  access  to  data  base  resources 

User  Interface:  The  DBS  interactive  interface  to  users  is  graphically  oriented  in  the  form  of 
a  multi-window  environment,  whereby  graphics  are  presented  in  concert  with  functional 
menus,  entry  of  geographic  parameters,  and  highlighting/annotating  of  processing 
results.  External  (Applications  Software  Interface)  access  to  the  DBS  is  limited  to  a 
menu-oriented  non-graphic  environment.  All  DBA/analyst  interaction  is  controlled 
through  the  man-machine  interface  (MMI).  The  MMI  encompasses  the  menu  interface, 
hierarchically  organized  functional  access,  and  display  processing  (where  appropriate) 
required  to  communicate  with  the  user,  invoke  functional  processing,  and  report 
processing  status  and  results. 

Views  of  the  Data:  The  interactive,  background,  and  external  applications  typically 
interface  with  the  data  base  on  a  sub-schema  basis,  whereby  selected  portions  (i.e.,  AOI, 
data  type,  feature  type,  attribute  set)  of  the  overall  data  base  are  accessed  during  a  user 
session.  Meta-data  exists  which  provides  information  about  the  data  base  contents  and 
can  be  accessed  in  the  form  of  directories,  coverages,  and  data  base  and  data  set  content 
summaries. 

Concept  of  Master  vs.  Temporary  Data:  Holdings  data  exists  at  two  levels  within  the  DBS 
data  base,  as  master  holdings  and  as  temporary  holdings.  Master  holdings  are  those 
which  have  been  fully  entered  into  the  DBS  data  base,  and  which  cannot  be  modified, 
archived,  or  deleted  except  by  the  DBA.  Temporary  holdings  are  those  which:  are 
created  through  the  data  manipulation  functions  as  pan  of  creating  data  to  be  exponed  to 
the  CATSS  Applications  Software;  are  in  the  process  of  being  initially  entered  into  the 
DBS  as  master  holdings;  or  have  been  received  from  the  CATSS  Applications  Software 
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and  arc  in  the  process  of  being  validated  for  entry  into  the  DBS  data  base.  Temporary 
holdings  are  also  created  as  by-products  and  intermediate  data  as  directed  by  users  of  data 
manipulation  functions  of  the  CATSS  DBS,  such  as  holdings  data  which  is  copied  and/or 
filtered  for  experimentation  purposes. 

The  operational  characteristics  described  above  are  accomplished  via  the  standard  DBS 
interactive  multi-window  graphic  interface  and  the  supporting  non-graphic  single-window 
Applications  Software  Interface  (ASI).  The  standard  CATSS  Data  Base  System  (DBS)  consists  of 
a  multi-window  interactive  graphic  interface  that  provides  the  user  with  a  variety  of  functionality  to 
view  and  process  data  holdings  of  the  DBS.  The  Application  Software  Interface  (ASI)  to  the 
CATSS  DBS  is  a  menu-oriented  non-graphical  interface  which  was  designed  to  perform  many  of 
the  same  data  access  and  manipulation  operations  as  the  interactive  DBS  interface,  but  without  the 
graphic  window  support.  The  design  and  functional  interaction  supported  through  the  menu- 
oriented  MMI  was  developed  using  c  source  code  (to  access  System  9  menu  handler  utilities)  and 
Unix  shellscripts  (for  ATB_viewer  commands). 

The  CATSS  DBS  MMI,  including  display  characteristics,  menu  layouts,  user 
communication,  and  process  invocation,  was  tailored  as  much  as  possible  to  conform  to  the 
System  9  GIS  MMI.  Figure  4-3,  “CATSS  DBS  Top-Level  Menu  Interface,”  illustrates  the 
standard  layout  and  content  of  the  Sun  console  window  for  the  standard  CATSS  DBS  interface. 

Throughout  an  interactive  session,  the  CATSS  DBS  displays  an  overview  graphics 
window  (upper-left  in  the  figure)  representing  current  data  base  holdings.  In  addition,  a  menu 
window  (right  side  of  the  figure)  allows  the  user  to  interact  with  the  CATSS  DBS,  via  mouse  or 
keyboard  control,  to  peruse  and/or  modify  data  base  holdings.  Functionality  of  the  DBS  is 
organized  according  to  the  type  of  access/manipulation  required.  Briefly,  the  functionality 
available  through  the  DBS  interactive  interface  is  described  as  follows: 

Geographic  Area  Functions:  During  an  interactive  DBS  session,  the  user  is  provided 
with  a  view  of  Master  and  Temporary  Holdings  on  a  worldwide  basis  via  the  Database 
Holdings  Partition.  A  Geographic  Area  provides  a  viewport  into  these  holdings  at  a 
larger  scale.  A  Geographic  Area  is  a  logical  entity  named  and  defined  by  a  minimum 
enclosing  rectangle.  This  allows  the  user  to  view  holdings  within  a  Geographic  Area 
(i.e.,  ad  hoc  area  or  pre-defined,  user-named  area  such  as  United  States,  for  example). 
Functionality  is  provided  to  allow  the  user  to  Create  or  Delete  a  Geographic  Area. 
Display  and  Remove  Display  allows  creation/removal  of  an  additional  graphic 
window  containing  holdings  information  limited  to  the  area  covered  by  a  Geographic 
Area.  List  provides  information  about  existing  Geographic  Areas. 
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Figure  4-3.  CATSS  DBS  Top-Level  Menu  Interface 
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Holdings  Maintenance  Functions:  These  functions  are  used  to  manipulate  either 
Temporary  or  Master  Holdings  as  specified  below. 

Input  -  allows  input  of  a  Temporary  Holding  from  data  in  an  external  forma  t/model 
which  is  acceptable  as  input  to  the  DBS. 

Delete  -  allows  a  Temporary  Holding  to  be  removed  from  the  DBS. 

Archive  -  allows  a  Temporary  Holding  (or  Master  Holdings  for  DBA)  to  be 
archived  to  secondary  storage.  Archival  may  take  place  to  disk  or  magnetic  tape, 
and  original  holding  may  remain  on  line. 

Create  -  provides  mechanism  for  creation  of  an  empty  Temporary  Holding  (useful 
for  data  which  originates  on  DBS  from  hand-digitized  data). 

Rename  -  allows  a  Temporary  Holding  to  be  renamed. 

Restore  -  allows  restoration  of  a  Temporary  Holding  (or  Master  Holdings  for  DBA) 
from  an  archived  copy. 

Extract  -  provides  extraction  of  a  new  Temporary  Holding  from  various  combina¬ 
tions  of  other  Master  or  Temporary  Holdings,  including  specification  of  area  of 
interest  and  feature  content  limitations. 

Copy  -  allows  a  copy  of  a  Temporary  Holding  to  be  made. 

Output  -  provides  mechanisms  to  reformat  a  Temporary  Holding  and  converts  it  to 
an  external  model/format  which  is  supported  under  the  DBS. 

DTED-Temp  -  a  special  support  utility  which  provides  conversion  of  DTED-  formatted 
elevation  matrix  data  to  a  vector  model  Temporary  Holding  so  that  it  may  be  viewed 
and  modified  using  standard  System  9  functionality,  including  the  Digital  Terrain 
Model  processing  utility. 

List  -  this  function  provides  a  list  of  all  holdings  of  interest  to  the  user.  Information 
may  be  selected  based  upon  area  of  interest,  status  of  data,  type  of  data,  etc. 

Add  -  a  DBA-only  function  which  provides  addition  of  a  Temporary  Holding  to 
Master  Holdings. 

Display/Edit  -  provides  direct  access  to  a  Temporary  Holding  under  System  9. 
Specifically,  the  user  would  most  often  elect  to  execute  the  System  9  Data  Capture 
and  Edit  (DCE)  utility  which  provides  extensive  functionality  to  display,  query,  and 
manipulate  data  within  a  Temporary  Holding. 
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Applications  Support  Functions:  No  Applications  Support  Functions  arc  currently 
implemented  under  the  CATSS  DBS.  The  menu  provides  a  placeholder  for  functionality 
that  might  be  desired  for  CATSS  Applications  at  a  later  date.  Suggested  functionality 
includes: 

Elevation  Matrix  Regrid  -  a  function  that  would  allow  conversion  of  elevation 
data  between  a  DTED  Level  1  and  Level  2  resolution. 

Generate  3D  Feature  Data  -  a  function  that  would  allow  creation  of  a  three- 
dimensional  (x,y,z)  holding  using  a  two-dimensional  holding  and  an  elevation 
matrix  over  the  same  area  of  interest. 

Display  Options:  Various  types  of  basic  graphic  display  manipulation  operations  are 
provided  through  the  generic  Display  Options.  These  include: 

Screencopy  -  takes  an  image  (screendump)  snapshot  of  the  contents  of  the  Sun 
console  window  and  saves  it  to  a  named  file. 

Pan  -  provides  basic  functionality  to  pan  across  (alter  the  center  of)  the  current 
graphic  display. 

Zoom  -  provides  basic  functionality  to  rescale  (viewing  more  or  less  data  detail)  the 
current  graphic  display. 

Mouse  Location  -  returns  the  geographic  latitude/longitude  coordinates  for  a  user- 
specified  mouse  location  within  the  graphic  display. 

Show  Meta  Info  -  used  to  obtain  detailed  information  about  specific  meta-data 
viewed  on  the  graphic  display. 

Display  Options  -  provides  various  subfunctional  display  manipulations,  such  as 
data  filtering,  textual  annotation,  etc. 

Fea/Attr  Defn  -  provides  access  to,  and  query  of,  the  CATSS  DBS  FACS-based 
schema  definition. 

Help  -  provides  access  to  on-line  help. 

EXIT  -  used  to  terminate  the  CATSS  DBS  interactive  interface. 
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MISSION 

OF 

ROME  LABORATORY 

Rome  Laboratory  plans  and  executes  an  interdisciplinary  program  in  re¬ 
search,  development,  test,  and  technology  transition  in  support  of  Air 
Force  Command,  Control,  Communications  and  Intelligence  (C3I)  activities 
for  all  Air  Force  platforms.  It  also  executes  selected  acquisition  programs 
in  several  areas  of  expertise.  Technical  and  engineering  support  within 
areas  of  competence  is  provided  to  ESD  Program  Offices  (POs)  and  other 
ESD  elements  to  perform  effective  acquisition  of  C3I  systems.  In  addition, 
Rome  Laboratory's  technology  supports  other  AFSC  Product  Divisions,  the 
Air  Force  user  community,  and  other  DOD  and  non-DOD  agencies.  Rome 
Laboratory  maintains  technical  competence  and  research  programs  in  areas 
including,  but  not  limited  to,  communications,  command  and  control,  battle 
management,  intelligence  information  processing,  computational  sciences 
and  software  producibility,  wide  area  surveillance/sensors,  signal  proces¬ 
sing,  solid  state  sciences,  photonics,  electromagnetic  technology,  super¬ 
conductivity,  and  electronic  reliability/maintainability  and  testability. 


